Thanks for the feedback, allow me to comment some thoughts:

1. Regarding the name ThingEnriched, I picked that name to be consisten with the other types: ThingLink and ThingDirectory. Although I agree that it could be odd having the adjective, if we specify the type as EnrichedThing it will not be that aligned with the other two. Maybe the solution could be changing "Enriched" to something else?
2. The classes ThingLink and ThingDirectory must be sub-classes of EnrichedThing in order to inherit the terms: created, modified, ttl, expires, etc. If these terms will not be use by ThingLink and ThingDirectory, then they should be sub-class only of td:Thing. Can you clarify to me if they inherit these terms?
3. Regarding the flattening, whenever we include the class ThingEnriched then inevitably the description will be flattened. What should we do? do we wait for the topic to be closed (and if we choose to flatten) proceed with the PR or do I remove the ThingEnriched class and leave the model with the RegistrationInformation as it was before?
4. I tried to bind schema:creationDate to discovery:creation, but I got an error (I will see if I can solve it). Anyway, it is normal to have different schemas in RDF. If we want to avoid this we could get rid of the schema and make our own terms; however, I think is better to rely on schema. I will try to see if I can bind them in the context, but if not (which may occur) we will need to decide if either remove schema and have a unified prefix, or have schema and discovery prefixes.

1. I also think "EnrichedThing" is better. It may be inconsistent, but that's English for you.
2. A ThingDirectory is not, itself an EnrichedThing so should probably not inherit from it. If a TD for a directory will have this extra data, it will only be if it appears in another directory... in which case, we will want to enrich a ThingDirectory TD. Is this use case covered? Can we enhance a ThingDirectory with enriched data? BTW I think this is one reason I prefer the simple use of an extension vocab, otherwise we get tangled up in inheritance trees.
3. depends on whether we adopt an inheritance structure or not, and what it is.
4. depends on whether we adopt an inheritance structure or not, and what it is.

The classes ThingLink and ThingDirectory must be sub-classes of EnrichedThing in order to inherit the terms: created, modified, ttl, expires, etc. If these terms will not be use by ThingLink and ThingDirectory, then they should be sub-class only of td:Thing. Can you clarify to me if they inherit these terms?

A new thing can have two types to inherit both EnrichedTD and ThingDirectory/ThingLink, unless diamond inheritance is not allowed.

After looking at the text, I feel that ThingLink and ThingDirectory types don't really fit inside this diagram under Directory Information Model. The diagram is "The ontology of a TD that can be stored in a Thing Description Directory". Those other types are already in another diagram (see #181) and aren't specific to the directory. If the goal is to have a single ontology diagram for the whole discovery, it should be moved to another section of the spec.

I propose the following:

Caption: The ontology of an Enriched Thing.

Adding those other types makes things confusing. Note that any Thing can be enriched, not just those with discovery-specific types:

The diagram is "The ontology of a TD that can be stored in a Thing Description Directory"

Agree on this, maybe after solving the issue with the model I will modify the PR so that section appears if this is ok with the rest.

Regarding the model provided by @farshidtz

The problem with it is that a TD marked with @type : discovery:ThingLink can not have the attributes of the enriched thing (discovery:ttl, schema:created, etc.) because the class having those types is discovery:EnrichedThing through the attribute discovery:hasRegistrationInfomation. One may say: "ok, then let's mark the TD as discovery:EnrichedThing", but doing so there is no way to know if the TD was actually a discovery:ThingLink or discovery:ThingDirectory because discovery:EnrichedThing is a sub-class of both (which I think is actually incorrect from the modelling point of view).

As a solution, we could have three types that are sub-class of td:Thing that are discovery:ThingLink, discovery:ThingDirectory, and discovery:EnrichedThing. In order for them to have the registration information we could assign to the td:Thing the property (and associated class) discovery:hasRegistrationInfomation. The diagram would be:

However, my concern is that the previous model could lead to situations in which a directory has an EnrichedThing registered by the user that may not have RegistrationInformation. In theory this would not be incorrect, but maybe will not make much sense. I think this latest diagram (adding some missing attributes) could do the work. As last remark, and sorry for putting this again on the table, it sounds odd to have discovery:ThingLink, discovery:ThingDirectory, and then discovery:EnrichedThing. Maybe we should rename it for another thing that can follow the pattern discovery:ThingXXX, e.g., discovery:ThingRegistered.

The problem with it is that a TD marked with @type : discovery:ThingLink can not have the attributes of the enriched thing (discovery:ttl, schema:created, etc.) because the class having those types is discovery:EnrichedThing through the attribute discovery:hasRegistrationInfomation. One may say: "ok, then let's mark the TD as discovery:EnrichedThing", but doing so there is no way to know if the TD was actually a discovery:ThingLink or discovery:ThingDirectory because discovery:EnrichedThing is a sub-class of both (which I think is actually incorrect from the modelling point of view).

A thing can have multiple types and inherit from all. As proposed above, the simplest way IMO is it to avoid letting the types inherit from each other and let the final Thing inherit selectively. This just boils down to:

As last remark, and sorry for putting this again on the table, it sounds odd to have discovery:ThingLink, discovery:ThingDirectory, and then discovery:EnrichedThing. Maybe we should rename it for another thing that can follow the pattern discovery:ThingXXX, e.g., discovery:ThingRegistered.

I'd read just read them as in natural language:

• ThingDescription: thing description i.e. description of a thing
• ThingModel: thing model i.e. model of a thing
• ThingLink: thing link i.e. link to a thing
• ThingDirectory: thing directory i.e. directory of things
• EnrichedThing: enriched thing i.e. a thing that is enriched
• PartialTD / AnonymousTD the same (maybe should change those suffices too.)

A thing can have multiple types and inherit from all.

I do not agree with this, a Thing is a td:Thing and then can one of the following: an EnrichedThing (a regular Thing with registration information), or a ThingLink, or a ThingDirectory. A td:Thing can not be at the same time a EnrichedThing (a regular Thing with registration information) and a LinkThing, or be at the same time a LinkThing and a ThingDirectory...right?

For sure a td:Thing may have registration information (and therefore I think it is ok having the relationship to RegistrationInformation). But it can not be said that a Thing is a ThingLink and at the same time a ThingDirectory. If this is not the case can you provide an example?

In addition, regarding my concern, can a user specify a td:Thing as am EnrichedThing (a regular Thing with registration information) but do not specify such registration information? because if that is the case, then it makes no sense having EnrichedThing. I recall we introduced this class to flat the TDs and because in the text the enriched thing appeared and, thus, it made sense.

IMO, a Thing can be a ThingLink and EnrichedThing at the same time (i.e. registered ThingLink). It could also be all of ThingLink, ThingDirectory, EnrichedThing (i.e. a registered directory with full TD available elsewhere).

can a user specify a td:Thing as am EnrichedThing (a regular Thing with registration information) but do not specify such registration information?

The registration information are optional, and EnrichedThing inherits the td:Thing. So while it makes no sense to use EnrichedThing if there are no registration information, this should not be explicitly disallowed.

As discussed with @AndreaCimminoArriaga, I have added the ontology diagram and updated text as part of PR #181 to avoid conflicts.

This PR will be narrowed to just update the files under /context.

I updated this PR with the model discussed with @farshidtz, ready for feedback ;)